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1. TEE LANGUAGE 


INI'RODUCTION 


SSI- (Software Specification Language) is a new forma- 
lism for the definition of speci'fications for software systems. 
The language provides a linear 'format for the representation 
of the information normally displayed -in a two-dimensional 
module inter-dependency diagram. In comparing SSL to FORTRAN 
or ALGOL, one finds the comparison to be largely complementary 
to the algorithmic (procedural) languages. SSL is capable of 
representing explicitly module interconnections and global 
data flow, information which is- deeply imbedded in the 
algorithmic languages. On the other hand, SSL is not designed 
to depict the control flow within modules, ¥e refer to the 
SSL level of software design which explicitly depicts inter- 
module data flow as a functional if ion , 

We wish to express our a.ppreciation to Mr. Bobby 
Hodges of Data System Labor tory, George C. Marshall Space 
Flight Center for fiis guidance and support in the performance 
of this task. 

l-l-l Need for SSL 

The current state of the art in software development 
permits insufficient formal evaluation prior to implementation. 
Such questions as: 

• Are all requirements fulfilled? 

• Have all softv/are elemenns been defined? 

• Are the element interconnections consistent? 

cannot be answ’ered in a manner that is independent of the 
designer's opinion. The intent of SSI^ is to formalize, through 
a language, the statement of the functional specification for 
a softw'are system. Given this formal statement expressed in 
SSL and a translator for the SSL language, an independent 
evaluation of the software may begin much earlier in the 
development cycle. 


m 
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In addition to evaluation, other aspects of SSL can 
aid both the designer and implementer . Several things that 
are characteristically omitted or inadequately performed 
during early design but required in SSL are; 

• - A complete and consistent, statement of the 

software requirement 

• Unamb'iguous communication of software organiza- 
tion to the detailed designer 

• Enumeration of intraprogram consistency checks 

(assertions) useful during checkout. 

A translator also provides tables and summaries for the final 

software documentation and a software element cross reference 

file. The latter could be used to statically verify the 
fidelity of the final code to original specifications. 

1.1.2 Unique Features of SSL 

i.xxc; major con t.r tout xon of SSL is the formal approach 
it brings to a phase of software development previously 
relegated to heuristic techniques as discussed above. ■ Within 
this framework, there are several unique technical features 
possessed by SSL. First, the projection of a specialized 
form of software requirements onto the objects" being defined 
establishes a rationale for the software structure not present 
in other methodologies. These requirements are an important 
aspect of consistency checking when evaluating a specific 
functional design. ’ Second, the incorporation of levels of 
abstractions directly in a design methodology is a step forward 
in software engineering. Lastly, an automated SSL translator 
is being designed that is one of several interlocking software 
design and evaluation tools collectively called Software 
Specification and Evaluation System (SSES). SSES includes a 
static code analy-zer, a dynamic code analyzer, and a test 
case analyzer. The specific capability that SSL brings SSES 
is the ability to test and evaluate software design early in 
the development cycle. 
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SSL also incorporates a flexible data abstraction 
capability and places emphasis -on assertions as a means of 
describing the dynamic behavior of the -software being designed. 
Although neither of these is unique, they are relatively new 
concepts in the field of computer stiience. 

1.1.3 Background , 

In evaluating a new soft^vare system, particularly a 
programming language, it is important to trace the historical 
developments to which it relates and upon which it is based. 

The MIL (Module Interconnection Language)' system [l] was a 
principal contributor to the concepts of data creation and 
data availability restrictions among modules within SSL, 
Guidelines imposed for the partition of programs into sub- 
systems are derived from the principles embodied in the concept 
of levels of abstraction [2] . Module descriptions in SSL 
are a linearlized form of the information available in the 
two-dimensional diagrams referred to as structure charts [3 ]. 

The data description capability is largely the same as that of 
PASCAL [4]. The syntax for expressions is derived from, but 
not identical to, that of ALGOL 60 [5]. Assertions in SSL 
have the form and appearance of those in the language 
NUCLEUS [6 ]. 
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THE GRAMME 


The material in this section is arranged in the form 
of a reference guide to the language, and not -tutorially in the 

r 

manner, of a user's manual. To aid the reader, a cross reference 
index is provided in the last section. 

1.2.1 Metalanguage Description 

For the purposes of automatic translation and unambig- 
uous communication, it is desirable to express SSL via a formal 

II 

grammar. The vehicle selected for this purpose is the Backus- 
Naur-Form (BNF) metalanguage BHF has the advantages of being 
well known and compact in representation. In addition, most 
formal methodologies for analyzing grammars are based upon 
BNF representation. 

Any nontrivial language contains an infinite number of 
legal sentences. Each sentence, in turn, is composed of the 
concatenation of strings; strings are composed of characters. 

A grammar uses strings as operands and combines them under the 
operation of concatenation to finitely depict, all legal senten- 
ces. The way in which this is done in BNF can best be inter- 
preted via an example. Consider the following production: 

<ab> « ajbj <ab> a 

Sequences of characters enclosed within the brackets < >repre- 
sent metalinquistic variables called nonterminal symbols. The 
marks and "j" are metalinquistic connectives meaning "Is 

composed of" and "or" respectively. Any string not a nonterminal 
or connective denotes itself and is called a terminal- symbol . 
Juxtaposition of symbols between connectives in a formula, such 
as the example, signifies that the symbols must be in the exact 
order denoted. The above production indicates that <ab> may 
pave the values: 





• • a 

• b 

• S. ^ 3.3^^ 3r3r3r j • * • 

• b, ba, baa, . . . 

In BNF, the null string is designated by <empty> ; ; = 

SSL is represented as a context-free grammar which 

means : 

e There exist a finite number of productions 
of the type of the above example. 

« The left part of each production (i.e., left 

of : :=) consists of a single nonterminal 
symbol . 


o There exists a unique nonterminal symbol (called 
the distinguished symbol) which is in the right 
part .of no production except its own. 

1.2.2 Overview of SSL Grammar - ’ 


Prior to examining the detailed structure of SSL com- 
ponents, it will be’ useful to identify the overall structure of 
a software specification expressed in SSL. Figure 1-1 depicts 
the sequencing of the syntactical items used to describe an 
SSL specification. 

A specification consists of one or more subsystems, 
each but the first having a name. The first subsystem is 

referred to as the "main" subsystem and each subsystem is 

* 

composed of a preamble and one or more module descriptions. 

The preamble defines the local environment for the subsystem 




1-5 















\ 

(constants, requirements, data formats, etc.) "and the module 

% 

-descriptions indicate operational aspects of program units 
(program units* are subprograms , procedures , etc . ) . 

In the following subsections, the detailed syntactical 
descriptions will be presented,' To facilitate cross referenc- 
ing, Section 2 contains an index of nonterminal symbols. 

V 

1-2.3 Basic Vocabulary 

The basic vocabulary of SSL consists of special 
symbols, letters, digits, and reserved words. Each special 
symbol (Table 1-1) is primarily a single -character except 
where limited computer character fonts require the concatena- 
tion of two characters. Where a special symbol consists of 
more than one character, it must be written without an inter- 
vening blank. Subsequently, special symbols other than 

and will be referred to as delimeters. Bach char- 
acter in Table 1-1 is available within the ANSI standard codes 
[^ 7 ]] for ASCII-8, EBCDIC-8, and HOLLER I TH- 256 . Substitutions 
may be necessary if an SSL translator is implemented in an 
environment not conforming to the standard character codes . 

Letters and digits do not have individual meanings 
blit are used to construct identifiers, numbers, and reserved 
words. The following basic productions enumerate these ele- 
ments of the yocabulary: 

<letter> ::= ajbj ... \z 
<digit> : 0|l|- ... |9 
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, TABLE 1-1 SSL SPECIAL SYMBOLS 


- [ 

• * 

j 
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, TABLE 

1-2 SSL EESERYED 

WORDS 

Access 

Fulfil- 

Transduction 

Accesses 

Fulfills 

Transductions 

Analog 

Global 

Transmit 

And 

Implies 

Transmits 

Array 

In 

True 

Assume 

Input 

Type 

Assumes 

Inputs 

Types 

Boolean 

Integer 

Use 

-Case 

Iteratively 

Uses 

Char 

Modify 

Using 

Conditionally 

Modifies 

Variable 

Constant 

Module 

Variables 

Constants 

Of ‘ * 

► 

Constraint 

Or 


Constraints 

Output 


Create 

Outputs 


Creates 

Real 


Digital 

Receive 


Doubleprecision 

Receives 


End 

Record 


Entry 

Requirement 


Equ 

Requirements 


Execute 

Satisfies 


Executes 

Satisfj' _ . 


Ealse 

Set 


File 

Subjectto 


For 

Subsystem 


Forall 

Text 


From 

To 




Serna ntics 


Identifiers must begin with an alphabetic character 
and contain onl-y letters, digits, and the symbol. The 
latter is known as the break character. Identifiers have no 
inherent meaning, but serve as identification for variables,' 
modules, subsystems, and other ' elements- of a software specifica— 

I 

tion. 

•Identifiers may be of arbitrary length but must be 
unique within the first twelve characters. No identifier may 
be equivalent to the first twelve characters of a reserved word. 
The same_ identifier may not be used to denote tv;o different 
quantities within a subsystem %yith the exception of field names 
in different records. 

1.2.4. 2 ' Numbers 
Syntax 

< unsigned interger> : ;-=<digit> J <unsigned integer> 

<digit> 


< sign >::=+[ 


< exponent part > : : = e <unsigned integer > 

[e <sign> <unsigned integer> 
' |d <unsigned integer> 

[d <sign> <unsigned integer> 

< decimal number > ; : = <unsigned integer > 

[<unsigned integer> . 



Examples 


14dl0 • 
3; 7 e-5 


Illegal ■ 

3,746 

XII 


Semantics 

Decimal numbers have their conven.tional arithmetic 
meaning. The exponent is a scale factor expressed as an integal 
power of 10. A number expressed with neither a scale factor nor 
a decimal fraction is assumed to be of type integer. A number 
which uses the "d” form for the exponent part is assumed to be 
double precision.' Otherwise, the number is assumed to be type 
real. Kote that if a number contains a decimal point, at least 
one digit must precede and succeed the point . 


1.2.4. 3 Logical Values 


<logical value> : := true [ false 
Semantics 

Logical values have their conventional meaning and may 
be defined by describing their combination under the operations 
’’union” and ’’intersection”. The union of the logical value true 
with any oth^r logical value always yields the result true . The 
intersection of th^ logical value false with any other logical 
value always yields the result false. 


/W 
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1.2.5 


Requirement Declaration 


The several parts of the ‘ requirement declaration • are 
used to -identify the data flow between the software package 
being described and other parts' of the^ total system. 'In add- 
ition, they identify'' processing steps„ (called transductions) 
and restrictions (called constraints) which are attached to both 
modules and variables. 

Syntax 


<requirement declaration> : := <requirenient or 

requirements > 

<requirement statement group > end 

<requirement or requirements> : := requiremeni 
[ requirements 


<requirement statement group> : := <requirement 
statement part> 

[ <requireraent statement group> ; 
<requirement statement part> 

<requirement statement part> : := <input part> 

j <output part> [ <transduetion part> 
j<constraint part> . 

1.2. 5.1 Input and Output Parts 

An input vis a system .level input (or stimulus) which 
a software package receives from an external source. An output 
is a system level response which has a purpose beyond the 
immediate concern of the software package being described. 




1-13 


Syntax 

<input part> :: = <input or input's > ontire 

variable list>-- 


<output part> : : = <output or outputs > <entire variable 
* ♦ * - 
list> 

<input or inputs> : : = input j inputs 
<output or outputs>:: = output [ outputs 


Examples 


e ipput state_vector ; 

9 inputs mass, velocity, distance ; 

^ output concordance_list ; 

Semantics 

A variable. may be in both an input and an output list. 
A variable i'n an output, list not used within the subsystem 
other than in the module in which it is initialized is not 
required to have a requirement transduction attribute. The 
structure of all variables in input and output lists must be 
described within the variable statements of the subsystem pre- 
amble. Each subsystem preamble must have a requirement declar- 
ation with an output part. 

1.2. 5. 2 Transduction Parts 

. Transductions are identifiers representing processing 
steps. They are derived by first writing a high level pseudo- 
program to "transduce" the input variables -into the output 
variables and then extracting and listing the major verbs of 
the program. Just as the processing steps of ,the pseudo-pro- 
gram may be nested, the transductions may likewise be nested. 
Ideally, for each subsystem there should be from three to 
seven transductions that are not nested within any others. 



1-14 


Sy ntax 


< transduction part> : : = <tTansduction or 

transductions ^ 

<trans duct ion clause> 

{ <transduction part> ; <transduction 
clause > 

< transduction or transductions >:: = transduction 
I transductions 

< transduction clause> : : = <transduction list> 

I <transduction list> iu <transduction 
list > 

< transduction list> : : = <transduction identiiier> 

j<transduction list >, <transduction 
xdentif ler> 

< transduction identifier : = <identifier> 

Examples 

m transduction sum_expense , sub__deduct in tax_compute; 

writ e_pay che cK ; 

• transductions save_options; read_card iu parse; 
Semantics 

Within a transduction clause, each processing step re- 
presented by a transduction identifier to the left of iR ®^st 
be a substep’ of the processing steps listed on the right of in. 
Each transduction 'identifier represents a unique processing step 
but may be reused to show different substep relationships. Sub- 
step relationships must be consistent, i.e., the complete set of 


substep relationships partially order the. transduction identif 
iers . 
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1.2. 5. 3 Constraint Parts 
Syntax 

< constraint part> : ;= <constraint or constraints> 

< constraint list> 

< constraint or constraints constraint 

[ constraints 

< constraint list > ::= <constraint identifier > 

|<constraint list >, <constraint 
identifier> 

< constraint identiiier> ::= <identifier> 

Example s 

© constraint carpool_size ; 

• constraints max_targets, ininimum_distance ; 

Semantics • . 

Each constraint identifier defined must be attached 
as an attribute to some module in the subsystem. 

1.2.6 Data Type and Variable Declarations 

Explicit description of data and the ability to define 
and use new data types is one of the greatest assets of SSL. 

A new data type may be described directly as part of a variable 
declaration, or described independently for subsequent use. 

Syntax 

< "type' declaration> : := <type or types> 

<type definition> 

j< -type declaration> ; <type definition> 

< type or types> type | types j global type 

[ global types 


I , < type def inition> ::= <identitier>. = . <type> 

j • 

<type>: :- <simple type> )<structured type> 

{<pointer type>.. 

r • 

; 

<variable dec^laration> : <’9ariable or variables> 

<variable definition> 

. [ <var table declaration^ ; < variable definition> 

■< variable or variables> ::== variable | variables 
< variable definition> <identifler list> :< type> 

|<identifier list> : <type> ; <for clause> 
|<identifier list> : <type> ; <stibjectto clause> 
j<identifier list> : <type> ; <for clause>j 

<suboecTto clause> 

<forclause> : for <transdnction list> 

<subjectto clause> : subject to <assertion list> 

< assertion list> : := <assertion> 

j< assert ion list> ; <assertiori> 

<identlfier list> <identifler> |<identifier list> , 
<identifier> 

Semantics 

■ A type declaration list is used to define new data 
types. Each type is named and may be referenced by the identi- 
fier to the left of in the <type definition> production. 

The normal spope of a type identifier is the subsystem in which 
it is defined. However, the scope of a global tj^pe is the 
entire SSL program. Global types may be defined only in the 
main subsystem. 
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A data .type need not be named if it is defined in- 
trinsic to the variable declaration. Both type and variable 
declarations may use data types defined and named elsev/here. 
Examples of both are given in the following subsections. 

3 /* * 

The <for clause> of the variable declaration is useci 
to attach requirement attributes. Requirement attributes limit 

t 

the availability of variables wirhin the modules of the sub- 
system. All variable declarations must contain a for clause 
with the exception of output variables identified in the require- 
ment statement . 

The <subjectto clause> identifies the global assertions 
associated with the variables being declared. A global 
assertion is one that must be true upon exit from the module 
creating the variable, and true on both entry and exit of modules 
using the variable. 

1.2. 6.1 Simple Types 

Simple types are data types for which the designer, 
using SSL, need not define the internal structure or the inter- 
nal structure has previously been defined and named. 

Syntax 

< simple type> : <basic type> [<scalar type> 

I <subrange type> ] ,<type identifier> 

< type identif ier> ; := <identifier> 


Semantics 
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1.2 1 6 . 1,1 Basic Types 

The basic data types are those which are implicity 
defined by the' SSL language. 

■< basic type> ; intt'ger j real | boolean 

I doubleprecision | char | analog { text 

Examples 

« variables I, J, K: integer ; for count_people • 

e variables height : real ; 

for record_status ; 

sub.jectto height >0.0 ; 

height <= 10.0 ; 

employed: boolean ; 

for record_status 

Semantics 

The types integer , real , boolean , and doubleprecision 
have the conventional meaning. The type char indicates a 
single unit of^hollerith information. Type text indicates 
hollerith data with unspecified length. Since the length of a 
text item varies, it may not be combined with other variables 
in forming structured data types. The type analog designates 
a data item which contains analog signal information. Like the 
jtext type, it may not be combined with other variables to form 
structured types. - 
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1.2. 6, 1.2 Scalar Types 

Scalar ^types are used to desiguafe a finite niunber of 
disjoint states which a variable may represent. In conventional 
programming languages, it is customary to declare the variable 
of type integ er and assign it only the cardinal numbers 1, 
n where each value represents . one state of the several possible. 


Syntax 

< scalar'type> : := ( <identifier list> ) 

Examples 

” type marital_status = (single, married, divorced); 
variable ms : raarital_status ; for emp_record; 

© variable color: (Red, blue, yellow., green) ; 


Semantics 

Gonceptuaily , the elements of scalar types are ordered 
regardless of whether or npt the underlying set of states is 
ordered. The order is always the same as that of the identifiers 
in the identifier list. This enables a designer to use rela- 
tional tests (< ,>, etc.) in assertions involving scalar type 
variables, 

1.2.6. 1.3 Subrange Types 

Subrange types are used to designate a subset of integ- 
ers or scalars which a data item may assume. 

Syntax 

< subrange type> ::= <constant> .. <constant> 

< const an1> : <unsigned integer> 

|<sign> <unsigned integer> 

[ (<constant identifier> 
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I |<sign> <constant identifier> - 
I <logical valtie> 

constant identlfier> /. := <identif ier> 

/ 

Examples 

e variables weight: 10.. 350; for ins_compute ; 

dependents: 0..15; for tax_compute; 

o type- color = (purple, blue, red, yellow, green, black): 
variable- ' primary_color : blue.. green; 

Semantics 

A subrange simply indicates the least and largest con- 
stant values an item may assume. The lower bound (left-most 
constant in the production) must be less than the upper bound. 

A subrange with bounds 'expressed in types other than integer or 
scalar is not permitted. 

Constant identifiers may arise from two contexts. The 
first is the appearance of an identifier to the left of in 
a constant declaration. The second (illustrated by the above 
example) is the appearance of an identifier as a scalar element. 
Constant identifiers arising from the second context may not be 
proceeded by a unary sign. 

1.2. 6. 2 Structured- Types 

A structured type is a data type composed of more 
elementary data types. 
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Syntax 

< structured type> : <array type> | <record type> 

I <digital type> | <set type> 

|<sequence type> 

% 

Semantics 

An SSL structured data type is used to indicate the 
general form and content of a data structure, not precise imple- 
mentation word and storage formats. In SSL, the following 
•definitions are used: 

I ’ Array - A fixed number of data items, all of the 

same type and length and accessed by 
computed index. 


Record - A fixed number of data items, each of fixed 
length, and each equally accessible. 

I 

Digital- A record having additional restrictions which 
are discussed in a subsequent subsection. 

Set - Ah element of the powerset of a finite number 
of basic elements. ' 

Sequence A variable number of data items, all of the 
or — - 

File same type and length; however, each element 
is not equally accessible at all times. 


Stronsrer connotations ("such as elements of an arrav are sen- 
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1.2. (6. 2.1 Arrays 

An array is a fixed number of data elements, each of 
the same type;- and length and each equally accessible. Elements 
of an array are ordered and each element is accessed by a 

cardinal number called its index. 

Syntax 

< array type >::= array £<index list>^’- of 

<component type> 

< index list> : <index type> |<index list> , 

<index type> 

< index type >:;= <siraple type> 

< component type> : := <type> 

Examples 

o variable matrix:- array Q 1 ..IO, 0..2oJ of real ; 

for ta, ; 

m type people = (adaras, .buckles, jones, smith); 
variable employee: array £peopleJ of 1..50 ; 

for ta; 
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Semantics 


Index types must have a finite range and be ordered.' 
This requirement eliminates index type of integer, real, and 
' double-precision. However, subranges of integers are permitted. 
For the purpose ,of ordering, false <true for boolean type 
indices . 

1.2. 6. 2, 2 Records 

V A record is a structure containing a number of com- 
ponents called fields. Fields are not constrained to be of 

identical type but must be of fixed length. A single record 
. / 

type is permitted to have variants. 

Syntax 

< record type> ; ;= record <field list> end 

< field list> : := <fixed part> j <fixed part> ; 

<variant part> j<variant part> 

< fixed part> : := <record section> j<fixed part> ; 

<record section > 

< record section> : <field identifier list> : <type> 

< field identifier list> <field identifier> 

I < field identifier list>' , <field identifier> 

< variant part> : ;= case <tag field> <type identifier> 

of <variant list> 

< variant list> : ;= <variant> | <variant list> ; 

<variant > 

< tag field> : <field identifier> : 

< field identifier> ; <identifier> 

•< variant^ ; <case label list> : (<field list> ) 

[<case label list> :( ) 

< case label list> : := <case label> I<case label list> 

* i 

< case label> 

<.case label> : : = < constant> 
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for health_f ile_update ; 

sub.jectto height >0; height <120; 

:weight .'>0. 0; weight <500.0 ; 


Semajgtics 

Fields may not be of basic types text or analog . A 
record may be a component of another, record ^ but a digital rype 
may not. The scope of a field identifier is the smallest record 
in which it is defined. Field identifiers with disjoint scopes 
may be reused. Access of a component is always by the field 
identifier and never by a computed value. 

, The type associated with the tag field of a variant 
must contain only a finite number of elements. This limits it 
to boolean, subrange, and scalar. All elements of the type 
must appear in some case label list of the variant. If the 

I 

field list for case label L is empty, the form is: 

L : ( ) 

A record may contain only one variant part and it must 
succeed the fixed part. However, a va,riant may contain variants. 
That is, it is possible to have nested variants. All field 
names of the same record must be unique even if they are in 
different variants. 

1.2.6. 2. 3 Digital Types 

Digital types are a restricted form of records to 
represent real time digital signals. 

Syntax 

<digital type> : := digital <fixed part> end 




• Variable 


Sagnal_In: digital 
Valve_l: boolean ; 

LOX_Sw^itch: l.,3; 

Command: (Idle, stopped, running) 
End ; 

for check__status ; 

Semantics 

Due to tbeir physical interpretation, the type of 
j components within digital types may only be boolean, scalar, 
or subrange. Digital types may not have variant parts and 
they may not be used as components of any other type. 


1.2. 6. 2. 4 Set Types 

Set types represent elements of powersets over a 
finite set of elements called the base type. Conceptually, 
a set type variable may be viewed as a bit string of length 
equal to the number of elements in the base type. Each bit 
is associated with a unique element and is "on" or "off" 
if the element is a member or not a member of the powerset. 

Syntax 


<set type> : := set of <base type> 
<hase type>::- <simple type> 


Examples 


0 Type members = (father, mother, big_sister, 

little_sister , big_sister, little_brother) ; 
Variable family: set of members; for arrange; 

© Variable Even_numbers : set of -10.. 10; 

for compute something . 


Semantics 


The b^e type must be' either ■scalar'cri- subrange. 

1.2.6. 2. 5 Sequence (File) Types 

A sequence differs from an array in that it may vary 
dynamically in- length, and is ref erenced . through a "window" 
called Its buffer (not by computed index). Examples of physical 
representations of sequences include linked lists and mass 
storage files. 

Syntax 

< sequence type> : <file or sequence> of <type> 

< file or sequence> : := file | sequence 

Examples 

e Variable Assembly: sequence of record 

part name: array of char ; 

order_no : integer ; 

drilled, punched, stamped, purchased: 
boolean 

End ; for up_date_orders ; 

I 

• • Type "roster entry = record 

name: array [l..20^^f char ; 
rank: 1..16; base_cbde: 1000.. 5000 

End ; 

Variable roster: file of roster_entry ; 

for assign new base ; 
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Semantics 


All components of sequences must be of identical type, 
and length. A sequence may not have sequence type or text type 
components Furthermore , digital and. analog types may not be 
combined as ' sequences . 

1.2. 6. 3 Poi.nter Types 

Variables of type pointer are "bound" to a particular 


type. That is, the contents of a pointer is used to indicate 

I 

a second variable, and the second variable is required to be of 
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1.2.7 


Constant Declarations 

I 

In SSL, constant- declarations may appear in the 

/ 

preamble of any subsystem and are used to communicate actual , 
values or parameters to the detailed designer. Normally, , 
a constant declaration would be used only for critical values, 
for which the effects are to be isolated in the final code. 

- Syntax 

< constant declaration> : := <constant or constants> 

<constant definition list> 

< constant or constants> constant i constants 
, < constant definition list> : := <constant definition> 

j<constant definition list> ; <constant definltion> 

< constant de±inition> : := <identifier> = <constant> 

1 <identifier> = <siraple type> 

Examples 

• Constant a = 10,0 ; max_count - Integer ; 

® Constants Low = true ; 

Tax_cut = 1 . . 5 ; 

Semantics 

An identifier declared equal to a simple type indicates 
that the exact value Is not known at the time of specification, 
but will be provided' before implementation.. An identifier used 
in a constant declaration may subsequently be used any place 
that a constant (of the same type) may be used. 
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<arrayl variable> : := <variable> 

. <e 2 c^ression list> : <expj: 9 ssio.n>.j<expression list> 

<expxession> 

<field deslgnator> ; <record’ variable> . <field 

/ 

identifier> 

<record variable> : := <variable> 

<file i)uffer> : <file variable> @ 

<f lie variable> : := <variable> 

Examples 

Cbar_Array [is] 

Inverse__Matrix {^3, I, is3 
Employee - Name 

Owner DO . Accessed_Valne 
Name_Record . Char act er 
Transaction_File @ 

Transaction_File @ . Date 
Trahsaction_Eile @ Date, Month 

Semantics 

Indexed variables have the conventional meaning. Field 
designators denote which field component of a record or digital 
signal type is to be selected. A file buffer variable designates 
the current active element of the sequence of elements that 
comprise the file. 



1 on 


Since arrays, files, and records' can be combined in 
various ways^ (a , record of records, '^ile of arrays, array of re- 
cords, etc,) a component variable can be arbitrarily complex. 

/ 

It is recommended that data structures be as limited in complex 
ity as the problem permits. 

• t 

1.2. 8. 3 Reierenced "Variables 
Syntax 

<referenced variable> : := <pointer variable> @ 
<pointer variable> : <variable> 

Examples 

Symbol_Pointer @ 

Student_Name @ 

Assembly©. Manufacturer© 

Semantics 


The data structure denoted by the contents of the 
pointer variable is substituted for the referenced variable 
in expression evaluation. 

' I 

1.2,9 Expressions and Assertions 

Expressions arise in two contexts: subscripts of 

arrays and as terras within assertions. Assertions may appear , 
in either variable declarations or module 'descriptions. 



1.2.9. 1 Arithmetic Expressions 

I 

• 

Arithmetic expressions in SSL are similar to those in 
other high- level languages. Results of ; expressions are single' 
valued with type determined by the operation and the con- 
stituent operands. 

Syntax' 

<arithmetic expression> : := <term> [ <sign> <term> 

|< arithmetic sxpression> <sign> <tsrm> 

<term> : := <factor> j <term> <raultiplying operator> 
<factor> 

<factor> : := <primary> [ <factor> ** <primary> j <set> 

<primary>' ; := <constant identifier> { <unsigned 

number> I <variable> j < function designator > 

I (<arithmetic expression> ) 

<set> : := [^<element list>^ 

<element list> <empty> { <element> | <element 
list>, <element> 

<element> : :=<expression> | <expression> .. 
<expression> 

< multiplying operator> : ;= + [/ 

<function designator> : := <f unction identifier> 
(<expression list> ) 


<function identifier> <identifier> 



Examples 


a + b ’■ 

3.0 * sin ( r + 1.0) -- • 

2 * (i]fix(c) + blanic__coinnion. X count) 

f 

name. fxeldl 
name__s'et + [joe, fret^ 

Semantics 

-Mixed, mode expressions are prohibited with the excep- 
tion of the exponentiation operator as indicated in Table 1-3. 
In Table 1-3, any operand of type integer may be replaced by 

an operand of type integer subrange. The symbol ’'dp" indicates 

^ * 

double precision. The unary may be used with any operand 
permitting a unary but is semantically superfluous (i.e. + 

is the identity operation). If a type is not included in the 
operand type columns of, Table 1-3 then its use with the desig- 
nated operator is not permitted. Note, however, that integer 
and integer subrange are interchangable. 

SSL does not contain intrinsically defined functions. 
All function identifiers are accepted, but it is suggested that 
those embodied in the proposed implementation language be 
adopted for each specification. Junction types are not explic- 
ity declared, but must be consistently used throughout the 
specification. In addition to the basic types (integer, real, 
etc.), the permissible function types include scalar and sub- 
ranges of integers and scalars. 
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tAbLE 1-3 



ARITHMETIC OPERATIONS 
VI "OP” V2 

VI Type V2 Type Result Type 



Integer 

Integer 


Real 

Real' •' 


dp 

dp 

Integer 

Integer 

Iijteger 

Real 

Real 

Real 

dp 

dp 

dp 

Set 

Set 

Set 

Integer 

Integer 

Integer 

Real 

Real 

Real 

dp 

dp 

dp 

Set 

Set 

Set 

Integer 

Integer 

Integer 

Real 

Integer 

Real 

Real 

Real 

Real 

dp 

Integer 

dp 

dp 

Real 

dp 

dp 

dp 

dp 


1 J 2 . 9 . 2 Boolean Expressions 


Combining arithmetic expressions with the boolean 
operations produces the expressions used- in' SSL assertions 
and array subscript lists. 

* V 

Syntax . 

< expression> ::= <implication> | <expression> equ 
< impl i cat io n > 

4‘mplication > : := <boolean terra> j <impllcation> 
implies <boolean term> 

V 

<boolean term> ::= <boolean f actor> ) <boolean term> 
<boolean factor> 

<boolean f-actor> : := <boolean secondary> j ^boolean 
,factor> and <boolean secondary> 

^boolean secondary > -= <boolean primary> h<boolean 
primary^ 

<boolean primary> : := <logical value> | <arithmetic 
expression> | <relation> | ( <assert ion> ) 

<relation> ::= <arithmetic expression><relational 
operatorxarithmetic express ion> 


<relation 9.1 operator> ; <|< 


= = ->: 


Exsjoplfes 


Rate =7.0 
Value and Qual 

^ f 

a>b Implies .c>O.Q 

S t Equ p<t 

Color ln~ j^yed> -green, yellowj - 

abs (buffer velocity) <16.0 and weight >= 14.0 

Semantics 

The arithmetic and boolean operators are grouped into 
hierarchial levels as exhibited in Table 1-4. Operations are 
performed in the order of highest hierarchial level first 
followed by equal hierarchial levels from left to right. This 
sequence may be overridden by parentheses, in which case the 
innermost operations are performed first. The meaning of the 
logical operators -i.(not), and , or , implies , and equ (equi- 
valent) is given in Table 1-5. 

Table 1-6 depicts the required operand types for the 
boolean and relational operators.* For set types, the symbols 
" stand for the empty set. When comparing set types to 
scalars, the base type of the set must be the same as that of 
the scalars. The operators <, <=, =, >=, ” stand for less 

than, less than or equal, equal, greater than or equal, 
greater than,, and not equal respectively. Relational operators 
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TABLE 1-6 BOOLEAN AND , HELATIOKAL OPEEATIONS 
VI '»OP’*. V2 


Operation 


Compare 


VI T 


Integer 

Real* 

dp 

Boolean 

Ch ar 
Scalar 


Integer^ 
Real 
dp ; \ 

Boolean 

Char 

Scalar 


Bo«51( 


In 

Set Inclusion 

Scalar 

Set 




Set 

Scalai* * 




Set 

Set < 

. Bool«an 



Suhrange 

Set 




Set 

Subrange 

V 

, 

Logical Inversion 

Boolean 

Boolean 

Boolean 

And 

Logical '*And" 

‘ Boolean 

Boolean 

Boolean 

Or 

Logical "Or” 

Boolean 

Boolean 

Boolean 

Implies 

Logical Impli- 
cation 

Boolean 

Boolean 

Boolean 

t 

Equ 

Logical Equi- 
valence 

Boolean 

Boolean 

Boolean 




.2.9.3 Assertions 

I 

Assertions are conditions which may assntme only true/ 
false valit.es. They are attached to variables at their point 
of declaration and to modules, Modulej assertions depict entry 
and exit data: conditions. 

Syntax 

<assertion> : <expression><forall clause> 

<forall clause> : <empty>] forall identifier =* 

<set> 

Examples 

a ~ ^*0 forall i 

(b.c = t forall j = [l,3,4..183) forall 

k=“[i6..3o3 

0 big>small 

•« code = 1 Implies (eof equ true ) 

Semantics • 

The scope of the identifier in the <forall clause> is 
.the assertion in which it is used and must not overlap that 
of a .local or global variable of the same name. Its type is 
assumed to be the base type of the set within the <forall 
clause>. The set must represent a finite number of elements 
and may not be empty. 

The expression within the assertion may assume only the 
values true and false. If the <forall clause> is present, the 
expression is evaluated once for each unique value which the 
<forall identifier> can assume from the set. 



1 



1 

lj.-2 , 10 Module Descriptions 

& 

I 

Modules are basic system objects in- an- SSL system 
description. , In using SSL, one identifies for. each module:' - 

j \ 

: / 

o The module name- 

« Input and' output data 

-© Conditions placed on data upon entry to and 
exit from' the module 

® Dependence of the module on environmental 

objects and other modules 

The rule of correspondence between input and output data is 
not stated in SSL. Its statement is a function of detailed 
design. 

Syntax 

<module description> ::= <module statement>; 

<module definition part> end 

< module definition part> : := <module definition 
statement> [ <module definition part> ; 

<module definition statement > 

< module definition statem'ent> : := <assumes statement> 
|<satlsfies statement >[ <fulf ills stateraent> 

I <accesses statement >| <modifies statement> 
[<creates statement> [ <uses statement^ 

[ <receives statement> | <transmits statement> 
[<executes statement> 



1.2.10.1 Module Statement 
< 

, 5*116 module statement is' always- the first statement' 
of a module description. It identifies the module by name 
and declares the local variables (if any). 

Syntax i 

<module statement> ::= <module or entT'w> <module 
identifier> <release variable group> 


< module or entry> : := module 1 entry 

< release* variable group> : <empty> j (<release variable 

list>) 

< release variable list> : <release variable> j <release 
variable list>; <release variable> 

< release variable> : := <variable > i<local variables> 
<local variables> : := <identifier list> : <simple type> 

< module identifier> : :=<identifier> 

Examples 

• iDodule matrix_multiply ; 

® entr y' push_stack (stack_item: stack_entry ) ; 

« module permutation (m, n : integer ; elements :p array); 



N 


Semantics 

A'-moduie statement- intr.oduced^by- mod-ale can only be 
refenencd3''‘-frdm within the subsystem in which it is declared. 

A -module statement introduced- by entry can be refer- * 
enced only from' subsystems other than the one in -which it is 
declared. 

Release variables occur both in module statements and 

r 

virtual references within execute statements. Local variables 
within a release group serve strictly for communication bet- 
ween the module and those calling it. In this respect, they 
differ from global variables declared in the subsystem pre- 
amble which serve to coramunica.te among modules having common 
requirement attributes. Local variable identifiers must be 
unique throughout a subsystem. Only the module statements 
introducing entry modules are permitted release variables 
which are not local variables. The variables o-f a release 
group for a module statement of an entry module must agree 
in type, number, and sequence to each virtual reference to 
it from other subsystems. 

1.2.10.2 Assumes and Satisfies Statements 

The assumes and satisfies statements specify truth 
conditions for data. 

Syntax 


<assumeSi statement> ; <assume or assumes> 
<assertion list> 

<satlsfies stateraent> : := <safcisfy or satisfies> 
<assertion list> 

< assume or assumes> : := assume | assumes 
< satisfy or satisfies> : satisfy i satisfie s 
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Examples 

V 

• Ass:ume ' a >0.0 ; 

J 

e Satisfies big ■sister 'in family; count- — 1 = 0 ; 
Semantics 

The assumes statement specifies data conditions 
that must be true upon module entry. The satisfies statement 
specifies data conditions that must be true upon module exit. 
Ya'riables used in assertions rnu"^" be either local variables 
in the release set or in the availability set pertinent to 
the module. (The availability set consists of those variables 
having requirement attributes which subsume all requirement 
attributes of the module.) 

1.2.10.3 Fulfills Statement | 

i 

The fulfills statement attaches requirement attributes 
to a module. 

Syntax 

<fulfills statement> : := '<fulfil or fulfills> 
<requirement attribute list> 

<requirement attribute list> : := <attribute identifier> 

I <requirement attribute list> , <attribute 
identifier> 

<attribute identifier> <transduction identifier> 
j <constraint identifier> 

<fulfil or fulfills> : := fulfil | fulfills 
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(j fulfills size_constraint , cluster; 
fi- ftilf il name_list 

> V 

Semsintacs 

All modules must have at least one transduction 
identifier attached as a requirement attribute. All attribute 
identifiers must be declared in the preamble to the subsystem 
in which the module is declared. 

1.2.10.4 Accesses Statement 

The accesses statement is used to indicate which 
environmental objects (chiefly peripherals) are utilized by 
a module . 

Syntax 

< accesses statement > : i= <access or accesses> 
<environmental object list> 

< access or accesses> : := access j accesses 

<.environmental object list> : := <environmental 

object identifier>l <environmental object list> , 
<environraental object identifier> 

,< environmental object identifier> : :=<identifier> 
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Examples 


■ • Access line_printer; 

# Accesses real_time__clo'ck, systeni_disk . ; 

t •' ! • ' 

t 

Semantics 

K . 

For each environmental object there must be a unique 
identifier for which the scope is the entire specification, 

1.2.10.5 Receives and Transmits Statements 

The receives and transmits statements are used to in- 
dicate real time data activity such as is associated with 
telecommunications, analog, and digital signals. 

Syntax 


<receives statement> : := <receive or receives> 

<fi'om clause> I <receives statement> ; <from clause> 

<from clause> : := <entire variable list> from 
<environraental object identifier> 

s 

<■ transmits statement> : := <transmit or transmits> 

<to clause> { <transraits statement> ; 

<to clause> 

<to clause> : := <entire variable list> 

<environmental object identifier> 


'<receijve or reeeives> : receive • {' receives 

< transmit or transraits> : := transmit [ transmits 

I * 

» f ‘ « 

i ^ I 

_ > f 

<entir:e vari^able list> : := <entire' variable> 

(<entire variable list> , <entire variable> 

r 

Examples 

a Receive weight from strain_gage_l ; 

« Transmits course_correction ^ ground_control ; 

Semantics 

The scope of the environmental object name is the 
entire specification. Note that components of structured 
variables may not be transmitted or received. 

1.2.10.6 Creates, Modifies, and Uses Statements 

The creates, modifies, and uses statements distinguish 
between input and output -data variables. They' may aTso in- 
dicate how the two are related in a manner short of a rule of 
correspondence. A complete rule of correspondence (algorithm) 
is a task of detailed design and not of SSL. 

Syntax • 

< creates statement> : := <create or creates> 

<create list> 


< modifies statement > : 
<raodify list> 


= <modify or modifies> 


■ /-yf. 



<nJodif5: list> : <variablfe ' lisrtxusing clauae> 

|<modify list>; <variable listxusing clause> 

J f ^ * 

<create’ list>: := <entire variable list><using clause> 
j<create list>; <entire variable listxusing clause> ^ 

I ^ 

<uf;es statement> : <ase dr us‘es>' <variable Hst> - ' 

■^create .or creates> : create j creates 

<modify’or modifies> : := modify I modifies 
<use or uses> : := use { uses 

<using elause> : ;= <empty> | using <variable list> 

<variable list> : <variable>l <variable list >, 

<variable> 


Examples 

e create emplo'yee_array using name_file; 
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Semantics 

I 

t * 

The order of the variable references in any variable . 
. ♦ } 

list has no significance. 

The variables within a using- c-lause or a uses state- 
ment are input • variables . A variable may be both input and out- 
put. An input variable in a using clause indicates that its 
contents are instrumental in determining the final contents of 
the output- variables within the same statement extending to the 
first semicolon on the left. 


The presence of a variable in the output list of a 
creates statement indicates the first use (in a dynamic sense) 
of- that variable. This does not mean, however, that the vari- 
able may not appear previously in the sequential listing of the 
SSL program. The implication of the creates statement is that 
all variables in the output list are first computed or initia- 
lized in the module' being described. All variables declared 
in the subsystem pre'amble must appear as an output variable in 
exactly one creates statement within the subsystem unless it is 
a release variable of an entry module. 


All variables appe'aring in a creates, modifies or uses 
statement (other than the output list of the .cjt'eates statement) 
must be in the availability set for the module. A variable is 
in the availability set of a module if the transduction require- 
ment attributes of the variable subsume all the transduction 
requirement attributes of the module, 


67# 
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1.2.10.7 Execute Statement 

The execute ■ statement designates modules which are 
called by the module being described. It may indicate that 
specific modules are^called iteratively, conditionally, or 
both . ' 

Syntax 

<.executes statement> ; := <execute or executes> 

<call list> i< executes statement>; <call list> • 

<call lisc> : := <module reference list>[ <module 
reference list> <call list tail> 

i<call list tail> 

t 

<call list tail> ; <iteratively clause > 
|<conditionally clause> ' 

I 

<iteratively clause> : iteratively <module 

reference list> | iteratively <call list tail> 


< conditionally clause> : := conditionally <raoSul^_=. 
reference list> 

<execute or executes >::= execute 1 executes 

<module reference list> ::= <module reference> 

{<raodule reference list> , <module reference> 


<module reference> : := <concrete reference> 
|<virtual reference> 


■<niodule identifier> 


<conci!pte referenc6> : 

. <virtual reference> ::= <subsystem identifier> . 

/ 

<module identxfierxrelease variable, graxip> 

d * 

E xamples 

•v. 

« Execute matrix multiply, cluster* group (poirxter®); 

® Execute* iteratively suba, subb; 

conditionally subc, subd, sube; 

e Executes sqrt; iteratively cos conditional ly sin; 

Semantics 

The order of module identifiers in the module reference 
lists is not significant. The domain of either an iteratively 
or conditionally clause extends to the next semicolon. An 
iteratively clause' may overlap another clause. 

Presence of a- module identifier in a iteratively clause 
connotates that it Is called from within a loop. Presence in 
a conditionally clause connotates the module is not always . 
called. If present in neither ^ the module is called unconr 
ditionaliy but not from within a loop, 

* ■ » 

A concrete reference is a call to -a module within the;] 
same subsystem. .A concrete reference may -never be ,to .an entry 
module, A virtual reference is a call to a module of a -V 

different subsystem and* must always be to an entry module,,.-'';^] 
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Within' the release ■ variable group, the- local variable 
format mast be used for . variables never before defined. A s’> 
variable may have been defined in the preamble to the sub- 
system or 3.n. the last module statement. The entry module 
to which the virtual ref erence ..refers must have the same 
release list -with respect to number, order, and type of 
variables. All variable types used in a virtual reference 
release list must be either intrinsically defined ( boolean , 
real , text , etc.) or global types. 

1.2.11 Subsystem Description s 

Subsystems are independent software units, each with 
its own requirement declaration. Subsystems may not share 
global variables but communicate via the release group var- 
iables of virtual references and entry modules. The only- 
identifiers w'ith scope greater than a single subsystem are 
global type identifiers, environment object identifiers, 
subsystem identifiers, and function identifiers. 

Syntax 

< subsystem descript ion> : := <subsystem preamble > ; 
<module description list> end 

<module description list> : := <module description> 
j< modtile description list>; <raodule 
description> 

' <subsystem preamble> <preamble declaration list> 

{ subsystem <subsystem ident‘ifier> ; <preamble 
declaration list> 


<subsystem iden.tif ier> : <jLcientiiier> 

<preamble declaration list> ;■:= <preamble declaratiou> 
!<preamble‘ declaration list> ; ^preamble 
declaration> 

f 

<preamble de‘claratiori> : <reqiiirement declaration> 

I<type declaration> I <variable declaration> 
[<constant declaration> 

<subsystem description list> : := <subsystem 

description> I <subsystem description list> ; 
<subsystem descript ion> 

< specif ication> : := <subsystera description list> 


Example 

a Requirement transduction sort_descend; input n, 
sort_array; output sort_array end ; 

Variable sort array: array []l..lOOo3 of real ; 
for sort_descend; 

sub.iectto sort_arrayri3 >0.0 forall i 
[l..n-l3 ; 

n:l. .1000; for sort_descend; 

Module - sort; 


fulfills 


accesses 


creates 

modifies 


sort_descend ; 

card_r,eader , line_printer ; 
n, sort_array; 

sort_array using n, sort_array; 


U 
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satisfies sort array jiH >= sort array 
. forall i = [^1 . . n- ' 

i 

End 

End 

End 

Semantics 

Each subsystem must have a requirement declaration 
that contains at least one transduction identifier and one 
output variable. There must also be at least one module 
description. The first subsystem declared (called the ’’main 
subsystem) does not have a subsystem identifier; all others 
must have a unique identifier. The scope of the subsystem 
identifier is the entire specification. 

The nonterminal symbol <specif ication> is the 
distinguished symbol of the SSL grammar. 



1 . 3 EXA5EPLE 


The example of this section was selected to demonstrate 
both-the descriptive level of SSL.jg,nd as many language elements 
as- possible? The requirement .'of the. problem may be stated as 
follows : 

"A program is required to process a stream 
•- o-f- telegrams . This stream is available as a 
sequence of letters, digits ’and blanks on, some 
device and can be* transferred in sections of 
predetermined size into a buffer where it is to 
be processed. The words in the telegram are 
separated by sequences of blanks and each 
telegram is delimited by the word 'ZZZZ* . 

The stream is terminated by the occurrence 
of the empry telegram, that is a telegram' 
with no words. Each telegram is to be pro- 
cessed to determine the number of' chargeable 
words and to check for occurrences of over- 
length words. The words 'ZZZZ* and 'STOP' are 
not chargeable and words of more than twelve 
letters are considered overlength. The 
result of the processing is to be a neat 
listing of the telegrams, each accompanied 
by the word count and a message indicating 
the- occurrence of an overlength word." 

To complete the problem statement, several assumptions are 
necessary. The follo\?ing alternatives were -selected for the 
purpose of this exposition: 
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• The character stream from which the telegrams 
are constructed resides on a drum having fixed 
length records; the record length itself is left 
an implementation option. • 

o The chargeable word count 'is the value 'to be 

printed and overlength words count as one word. 

® If a physical end of file is encountered before 
the logical end of the data stream, an error 
message and the partial telegram is printed. 

The software is organized into four modules as indicated 
by Figure 1-2. The purpose of each module is given in Table 
1-7. Figure 1-3 contains the SSL description of the telegram 
processor. The right margin of the statement listing contains 
reference notes to subsections containing detailed descriptions 
of the language elements used. 

A careful examination of Figure 1-3 will indicate an 
interesting application of the subsystem capability. The 
subroutines GET_CHAR and FILL_BUFFER occupy a separate sub- 
system with the sole purpose of handling file I/O, The char- 
acteristics of the device on which the telegrams' are stored 
are encapsulated within these two modules. 
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NOTES: 
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A 

t 
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1 
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"A" CALLS "B" ■ 
CONDITIONALLY 





"A" USn3 SYSTEM SERVICE “S" 


SAi-0312 


Pigure 1-2 Module Structure Chart for Example 







TABLE 

MODULE 

get_telegra:.j 

GET_WORD 
GET CHAR 


MODULE DESCRIPTIONS . FOR EXAMPLE 


• ' PURPOSE ' 

/ 

•^Collects v/ords belonging to each 
telegram and prints them in a neat 
manner along -with the chargeable 
word cotint . 

Collects characters into words and 
prints error messages denoting over- 
length word or physical record end 
of file. 

Returns the next character in the 
telegram file. 


FILL BUFFER 


Enters the next physical record 

from, the drum into the character buffer 




type cbaracter_Tecord “ array .record__let:gthJ of char ; 


variable character fila:secuenee of character record;- 


for read; 

buffer : charac te r_record ; 

for separate; 
a__cbar;char ; 

~ for separate: 
ehar_tndex: 1. .record-length; 

for separate; 
eof flac: booloan ; 

~ for separate — -. 


ead; /* end of subsystem preamble •/ 


c 


1 . 2.6 


/* subroutine to fetch next •/ 
/* character from fxle */ 





2 , INDEX 


Each reference in the left column is to a nonterminal 
symbol. The right column contains the number of the -sub- 
section i-'T:..-which the nonterminal is- -defined via one more' pro 
duct ions.' 


Access or accesses 

H 

• 

O 

Access statement 

1.2.10.4 

Arithmetic expression 

1.2.9. 1 

Array type 

1 . 2 .'6 . 2 . 1 

Array variable 

1.2. 8. 2 

Assertion 

1.2. 9. 3 

Assertion list 

1.2.6 

Assume or assumes 

1.2.10.2- 

assumes statement 

1.2.10.2 

attribute identifier 

1.2.10.3 

Base type 

1.2. 6. 2. 4 

Basic type 

1.2. 6. 1.1 

Boolean factor 

1. 2.9.2 

Boolean primary 

1 . 2 . 9 . 2 

Boolean secondary 

1.2. 9. 2 

Boolean term 

1.2. 9. 2 

Call List 

1.2.10. 

Call list tail 

1.2.10,7 

Case Label 

1.2. 6. 2. 2 

» 

Case label list 

1.2. 6. 2. 2 



Concrete reference 
Conditionally ’clause 
Component type, . 

Component variafcfle 
Constant 

Constant declaration 
Constant definition 
Constant definition list 
Constant identifier 
Constant or constants 
Constraint identifier 
Constraint list 
Constraint or constraints 
Constraint part 
Create list 
Create or creates 
Creates statement 
Decimal number 
Digit 

Digital type 
Element 
Element list 
Empty 

V 

Entire variable 
Entire variable list 
Environmental object identifier 
Environmental object list 


1.2-.10.7 
ja;2.10,7 
1.2. 6. 2.1 
■ 1,2, 8. 2 
■ 1.2. 6. 1.3 
1..2.7 
1.2.7 
1.2.7 

1.2. 6. 1.3 
1.2.7 

1.2. 5. 3 
1.2. 5. 3 

1 . 2 . 5 . 3 
. 1,2.5. 3 

1 . 2 . 10 . 5 

1.2.10. 6 
1,2.10.6 

1.2. 4. 2. 

1.2.3 

1.2. 6. 2. 3 

1 . 2 , B . 1 
1 . 2 . 9 :l 

1 . 2 . 8.1 

1.2.10.5 

1,2.10.4 


1-2,10.4 


Execute or executes 

Executes statement 

Exponent part ■ 

1 

Expression 
Expression list 
Factor 

Field designator 
Field identifier 
Field identifier list 
Field list 
File buffer 
File or sequence 
File variable 
Fixed part 
For clause 
Forall clause 
From clause 
Fulfil or fulfills 

s 

Fulfills statement 
Function designator 
Function identifier 
Identifier 
Identifier list 
Implication 
Index list 


• a. 2. 10 . 7 

. 1 . 2 . 10.7 
! 

■ 1 . 2 . 4. 2 

) 

1 . 2 . 9 . 2 .. 

t 

1 . 2 . 8 . 2 

1 . 2 . 9.1 

1 . 2 . 8. 2 
1 . 2 . 6 . 2. 2 
1 . 2 . 6 . 2 . 2 
1 . 2 . 6 . 2 . 2 
1 _. 2 . 8.2 

1 . 2 . 6 . 2. 5 
1 . 2 . 8 . 2 
1 . 2 . 6 . 2. 2 
1 . 2 . 6 ' 

1 . 2 . 9. 3 

1 . 2 . 10.5 

1 . 2 . 10.3 
1 . 2 . 10.3 
1 . 2 . 9.1 

1 . 2 . 9.1 

1 . 2 . 4.1 
1 . 2.6 

1 . 2 . 9 . 2 
1 . 2 . 6 . 2.1 




2-3 . 


Index type 
Indexed variable 
Input or inputs. 

Input part • 

Iteratively clause 
Letter 

Local variables 
Logical value 
Modifies statement 
Modify or modifies 
Module definition part 
'Module definition statement 
Module description 
Module description list 
Module identifier 
Module or entry 
Module reference 
Module reference list 
Module statement 

s 

Multiplying operator 
Output or outputs 
Output part 
Pointer type 
Pointer variable ’ 


1 . 2 , 6 . 2.1 
• li2.8.2 
1-.2.5.1 

42.5.1 

1^2.10.7 

i;.2.3 

1 . 2 . 10.1 

1 . 2 . 4. 3 
1 . 2 ', 10.6 
1 . 2 . 10.6 
1 . 2,10 
1 . 2.10 
1 . 2.10 
1 . 2.11 
1 . 2 . 10.1 
1 . 2 . 10.1 
1.2.10.7 
1.2.10.7 
1 . 2 . 10.1 

1.2. 9.1 

1.2. 5.1 
1.2. 5.1 

1 . 2 . 6. 3 

1 . 2 . 8. 3 


2-4 


Preamble declaration 
Preamble declaration list 
Prima’ry 

Receive, or receives 
Receive statement 
Record section 
Record type 
Record variable 
Referenced variable 
Relation 

" Relational operator 
Release variable 
Release variable group 
Release variable- list 
Requirement attribute list 
Requirement declaration 
Requirement or requirements 
Requirement statement group 
Requirement statement part 
Satisfies statement 
Satisfy or satisfies 
■Scalar type . 

Set 

Set type 
Sequence type 
Sign 


^ 1 . 2.11 

1 . 2.11 

/ 

; 1.2. 9.1 
1.2.10.5 
1.2.10.5 
1.2.6.2.i 
1.2. 6. 2.: 
1.2.8.2 
1 ’2.8.3 

1 . 2 . 9. 2 

1 . 2 . 9. 2 





r 


Simple “type 

\ 

Specification 

, j 

Structured type 

i 

Subjectto clause 

t 

ri 

Subrange type ^ 

Subsystem description 
Subsystem description list 
Subsystem identifier 
Subsystem preamble 
Tag field 
Term 

To clause 

Transduction clause 
Transduction identifier 
Transduction list 
Transduction or transductions 
Transduction part 
Transmit or transmits 
Transmits statement 
Type 

Type declaration 
Type definition 
Type identifier. 

Type or types 
Unsigned integer 
Unsigned number 


1 , 2 . 6.1 
' 1 , 2.11 
: .1 . 2 . 6 . 2 
i . 1 . 2.6 

t 

1 . 2 . 6 . 1.3 
■' 1 -. 2-.-11 
1 . 2.11 
1 . 2.11 
1 . 2.11 



' 2-6 



Use or uses 
Uses -statement 
Using clause 
Variant 
Variant list 
Variant part 
Variable 

Variable declaration 
Variable definition 
Variable list 
^•Variable or variables 
Virtual Reference 


1 . 2 . 10.6 
1 . 2 . 10.6 
;> 1 . 2 . 10.6 
i 1,2. 6. 2. 2 
1 . 2 . 6 . 2. 2 
1 . 2 . 6 . 2. 2 
1 . 2.8 
1 . 2.6 
1 . 2,6 
1 . 2 . 10.6 
1 . 2.6 
1 , 2 . 10.7 



2-7 



3-1 


